第2章 アジャイルにする理由
アジャイル開発が重要なのは、もっと深い哲学的、倫理的な理由があるからだ。そこにはプロフェッショナリズムと顧客のまっとうな期待が関係している。(Kindle の位置No.846-847)
規律のフレームワーク（結論）
開発プロセスではないと言っている
権利と期待をお互いが引き受けて協議するという規律のある専門性こそが、ソフトウェアの倫理的な基準の土台となる (Kindle の位置No.1289-1290)
お互いとは、開発者と顧客
Uncle Bobの立場は、サークルオブライフのプラクティスを約束とコミットメントとして捉えるというもの（「プロフェッショナリズム」）
専門分野を高めるコミットメント
自分がプロフェッショナルになる
プロフェッショナルとしての振る舞いを業界全体に広げていく
（Clean Craftsmanshipであった駆け出しが常に半数問題）
コンピュータシステムに取り囲まれている
ソフトウェアに依存した社会
IMO：software eating the worldを思い出した
我々、プログラマーが世界を支配している。しかし、お粗末（Uncle Bobの課題感）
（大いなる力には大いなる責任が伴う）
アジャイル開発の主要な目的の一つは、マネージャー、ユーザー、顧客からプログラマーへのまっとうな期待に応えること
Uncle BobをCTOとして、期待が述べられていく
応えるためのアジャイルのプラクティスと合わせて（技術プラクティスがよく出てくるかも）
（プラクティスの理解を深めた後に再訪するとよさそう）
品質が高く、欠陥が少ないシステム
現実はゴミのようなソフトウェアが多い
プログラマーによる人為的遅延がない
各イテレーションの終了時点でシステムが技術的にはデプロイ可能な状態でなければならない (Kindle の位置No.984-985)
重要な機能から作る
イテレーションの終わりにデプロイ可能にするために、テストなどすべてを含める
リリースはビジネス判断となる
時間とともに安定した生産性
大がかりな再設計は恐ろしいほど高くつくし、それがデプロイまでこぎつけられることはめったにない。(Kindle の位置No.1051-1052)
セカンドシステム症候群
安価に変更できる
ソフト（変更しやすい）ウェア（製品）
継続的かつ着実な改善＝ソフトウェアシステムも時とともによりよくなっていく
IMO：AoAD2e中でも見た記述！
問題を見つけたら放置せず、修正してクリーンにする
変更に対する恐怖
ボーイスカウト活動ができない
TDD
新しくリリースするものは徹底的にテストされていることを期待する
テストの自動化
開発チームは互いにカバーしあう
見積りがわかっていることとわかっていないことに基づく
相対見積り
答えが本当に「ノー」（できない）であるなら、「ノー」と言う
学び続ける
教える・教え合う
権利章典
『XPエクストリーム・プログラミング導入編』
顧客の権利と開発者の権利、相補的関係
顧客
確率ベースの計画を知る権利
開発者が常に最も重要な仕事に取り組むことを期待する権利 (Kindle の位置No.1229)
進捗の受け入れ基準を指定する権利。受け入れ基準を満たしていることを立証してもらう権利
要件を変更する権利
スケジュールに危険が及んでいることを知る権利
顧客にはスケジュールの順守を要求する権利がないことに注意してほしい。(Kindle の位置No.1245-1246)
スコープの変更によるスケジュールの管理に限定
開発者
要件の詳細と重要度を知る権利
要件や優先順位は変化するが、「イテレーション期間中の開発者は、これらを変化しないものとみなす権利がある」(Kindle の位置No.1256-1257)
イテレーション期間中は要件が変化しないがデフォルトでいいのか！
質の高い仕事をする権利
プログラマーがコミュニケーションを取る権利
助力を求める権利には、助力を求められたら応じる責任も伴う
見積りを行う権利（コミットメントにはならない）
プロの開発者には、仕事やタスクに対して、その都度「ノー」と言う権利がある。(Kindle の位置No.1275-1276)
仕事を引き受ける
引き受けると責任を負う（ここで挙げた権利を行使して果たす）